[Previous] [Next] [Index] [Thread]

Re: what are realistic threats?

>Assuming I'm right, what are the likely risks with WWW as it now exists
>due to passive listening?  These come to mind quickly:

Its not really the listening its the PUT and POST actions for forms. Most
people are more worried about people modifying their disk than reading it.

The number 1 priority is to stop the bad guys from getting in. Authentication
is the key.


>1) Reading credit card numbers.
Most of the reoprts I have read on `carding' rate the difficulty of obtaining
card numbers as low anyway. Basically it is an insecure and derranged system
That AMEX, VISA and co should fix PDQ. But we do need the encrypt for this
application to please the customer or they won't use the service.

>2) Reading username/password pairs for the Basic authentication scheme.
Basic authentication scheme to be discontinued. We now have a replacement
that does not involve sending password in plaintext, does not involve extra
maintenance nor patent concerns. Expect it in the next major code release
(ie the one after the one we did today).

>3) Reading responses (documents) from servers.
I don't think this is the priority but its an interesting and fun place to be
and its not too hard to encrypt the stuff comming back. What worries me though
is the use of an insecure encryption ending up providing a loophole. This is
quite a worry when RSAREF 40 bit keys come into the picture for non-US users.


>My point:  while we can (attempt to) design spook-proof security schemes,
>I think we can achieve a hugh part of what we really seek with relatively
>simple, low-cost technology.

Over egging the spec is a temptation that has to be resisted. It is very easy
to encrypt data that can easily be discovered out of band but thereby prevent
things like proxy servers from working. On the other hand you don't want to
have people thinking a product claiming security to be secure when it is not.

The credit card example is a misleading one. We cannot patch up an insecure
system by making a single part secure. When AMEX etc give out smatcards then
things might change here. We should not use the insecurity of credit card
transactions as an excuse to create tatty security. People here want to
run a nuclear experiment or two off HTTP so we want security.


Phill H-B
References: